File HB-001 for UI-path merge-queue enable; correct research doc §10.3#42
Merged
File HB-001 for UI-path merge-queue enable; correct research doc §10.3#42
Conversation
There was a problem hiding this comment.
Pull request overview
Updates documentation to reflect the current state of enabling GitHub merge queue: the REST API path is blocked (422 validation error), so the action is handed off via a filed human-backlog item with UI steps.
Changes:
- Correct
docs/research/parallel-worktree-safety-2026-04-22.md§10.3 to state the REST API blocker and the UI-path handoff (HB-001). - Add HB-001 to
docs/HUMAN-BACKLOG.mdwith the requested UI steps and desired ruleset parameters.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docs/research/parallel-worktree-safety-2026-04-22.md | Updates §10.3 to accurately describe the merge-queue ruleset enablement status and the REST API failure. |
| docs/HUMAN-BACKLOG.md | Adds HB-001 capturing the admin/UI action needed to enable merge queue on main. |
a1c7250 to
145ff57
Compare
HB-001 (HUMAN-BACKLOG): rewritten from admin-toggle ask to durable org-migration intent — AceHack/Zeta → Lucent-Financial-Group/Zeta — with Aaron's four 2026-04-21 quotes, preserve-all-settings constraint, public-from-start, no deadline, interim "accept rebase-tax" policy. Added top-of-file "Name attribution — explicit carve-out" section documenting the narrow exception to the BP no-names rule for the per-addressee For: sub-tables. docs/research/parallel-worktree-safety-2026-04-22.md §10.3: corrected resolution-path block to platform-gate diagnosis (gh api /users/AceHack --jq '.type' == "User" — merge queue is org-only at the platform level, not a public-beta quirk). Removes stale "no HB-001 filing needed" claim. .github/workflows/codeql.yml: added path-gate job so docs-only PRs satisfy the newly-enabled "Require code scanning results" ruleset rule. Path-gate runs git diff base...head over code-scanned paths (src/, test/, *.cs/fs, .github/workflows, .github/codeql, tools/setup); on docs-only PRs uploads two empty-SARIF files (actions + csharp) via github/codeql-action/upload-sarif so the CodeQL aggregate check records SUCCESS (analysis ran, zero alerts) rather than NEUTRAL (no results → fail under the new rule). Analyze matrix now gates on needs.path-gate.outputs.code_changed == 'true'. Push/schedule events always fall through to full analysis (safe default). Shell uses set -uo pipefail + decide_fallback_true() so any error opens the gate to full analysis — false-positive (extra run) beats false-negative (silent skip).
145ff57 to
07d912e
Compare
Addresses two P1 findings from Copilot review on PR #42: 1. Per-language SARIF upload categories. The previous single upload step used a fixed `category: "path-gate-no-code-change"` that overrode the per-language automationDetails.id set in each SARIF file. Result: GitHub code-scanning would see both languages under one generic category, not matching the `analyze` matrix categories (/language:actions/, /language:csharp/). Split into two upload steps so each language keeps its matching category — empty-SARIF now substitutes cleanly for the analyze-job output on docs-only PRs. 2. Fork-PR guard. The synthetic SARIF upload needs `security-events: write`, which GITHUB_TOKEN has downgraded on PRs from forks. Without a guard, docs-only fork PRs would 403 on upload and stay unmergeable when the code_scanning ruleset rule is on. The `decide` step now sets `code_changed=true` on fork PRs, forcing the full `analyze` matrix instead of the short-circuit; CodeQL's analyze has its own fork-PR permission fallback path. Header comment block #7 updated to document both behaviors.
This was referenced Apr 21, 2026
AceHack
added a commit
that referenced
this pull request
Apr 27, 2026
…ference (#42) Aaron 2026-04-27: "../SQLSharp is a good example of typescript post intall scripts too" While ../SQLSharp is primarily the pre-DBSP event-stream- processing seed (LINQ/SQL flavor), it also contains TypeScript post-install scripts that serve as good reference templates for the post-install→TypeScript pattern this strategy codifies. When porting bash post-install scripts to TypeScript, mine ../SQLSharp's TS post-install scripts for shape rather than rediscovering the patterns. Composes with the laptop-source-integration triage: post-install-script TEMPLATES are themselves a feature that either ships in-repo (port the templates) or design-docs the shape (capture conventions in docs/research/post-install-typescript-conventions.md). Per AgencySignature v1 (Otto-138): Author: Otto (Anthropic-side AI agent on the Zeta factory) Origin-substrate: AceHack/Zeta main Co-authored-by: Otto <noreply@anthropic.com>
AceHack
added a commit
that referenced
this pull request
Apr 27, 2026
…rence — LFG sibling of AceHack #42 (#643) * substrate: clarify ../SQLSharp also a good TypeScript-post-install reference (#42) Aaron 2026-04-27: "../SQLSharp is a good example of typescript post intall scripts too" While ../SQLSharp is primarily the pre-DBSP event-stream- processing seed (LINQ/SQL flavor), it also contains TypeScript post-install scripts that serve as good reference templates for the post-install→TypeScript pattern this strategy codifies. When porting bash post-install scripts to TypeScript, mine ../SQLSharp's TS post-install scripts for shape rather than rediscovering the patterns. Composes with the laptop-source-integration triage: post-install-script TEMPLATES are themselves a feature that either ships in-repo (port the templates) or design-docs the shape (capture conventions in docs/research/post-install-typescript-conventions.md). Per AgencySignature v1 (Otto-138): Author: Otto (Anthropic-side AI agent on the Zeta factory) Origin-substrate: AceHack/Zeta main Co-authored-by: Otto <noreply@anthropic.com> * fix(threads): restore deleted MEMORY.md entry + reword nonexistent-doc xref (Copilot P1 x2) Two unresolved Copilot P1 threads on this PR; both valid. Thread 1 (memory/MEMORY.md): the laptop-only-source-integration index entry was inadvertently removed alongside the install-strategy entry edit. Restore it — the memory file still exists and remains discoverable from the index. Also folds in the prior "outside enumerated history-of-the-work surface" qualifier on the done criterion (matches the AceHack-main version). Thread 2 (memory/project_install_script_language_strategy_*.md): the text referenced `docs/research/post-install-typescript-conventions.md` ambiguously ("capture the conventions in <path> or similar") which Copilot read as a claim that the doc exists. Reword to make explicit that this is a proposed future location, not a current reference. LFG sibling fix-forward — the AceHack equivalent of thread 2 will land via a separate small substrate PR on AceHack to keep the homebase-first invariant. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Otto <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Context
`merge_group:` trigger already landed on `main` via PR #41 — it's the hard prerequisite and is done. The ruleset itself is the final user-visible toggle. The REST API repeatedly rejected a well-formed payload (tried original params + docs-example params verbatim) with a truncated 422 body; known community limitation. UI path is a ~30-second operation.
This follows:
Also dogfoods `gh pr merge --auto --squash` for the second time as the new convention (first was PR #41).
Test plan
🤖 Generated with Claude Code